 |
| |
|
About FCDS
If your organization uses an LDAP server to maintain users, you can take advantage of FirstClass Directory Services (FCDS) to share Directory maintenance with FirstClass. FCDS is an optional component of FirstClass that allows you to:
• administer the FirstClass Directory from an external LDAP V.3 server (LDAP server)
• use an LDAP V.3-enabled client (LDAP client) to see a structured, hierarchical (tree) view of the FirstClass Directory
• use an LDAP server to authenticate users when they try to log into FirstClass.
 NoteWe assume that you are familiar with LDAP concepts such as hierarchies and naming conventions. If you aren't, you can find comprehensive information about LDAP on the Internet, or you can contact your organization's LDAP server administrator for help. You will need to work closely with this administrator anyway, to ensure that the FirstClass environment is set up to work properly with the LDAP server.
FCDS sits between the FirstClass server and the LDAP server. It can be installed on the same machine as the FirstClass server or a separate machine. FCDS can replicate information between the two servers, as in this diagram:
 Replication is controlled by the mode in which you run FCDS. You can run in LDAP, user replication or authentication only mode.
If the machine on which FCDS is running stops, FCDS will simply pick up where it left off, after you restart the machine.
Restrictions on duplicate names
We don't recommend duplicate public mail list names. FCDS treats public mail lists differently from users, because public mail lists aren't located in the Directory, but rather in the Mail Lists folder. Duplicate public mail list names will only work in certain circumstances in FCDS' standalone mode.
There are no restrictions for duplicate user names. If these names appear in different OUs, they will appear in different parts of the LDAP tree view, making them more distinguishable than in the traditional FirstClass Directory view. Because FCDS maintains the tree view by user ID as well as by name, there can also be duplicate user names in the same OU.
In addition, there can be duplicate OUs in the LDAP tree view. For example, Husky Planes can have an Administration OU in both its Toronto and New York branches.
Who can run FCDS
FCDS can be configured and run by the FirstClass administrator or, for example when clustering, by a subadministrator.
The subadministrator's Desktop must contain aliases of the Groups, Mail Lists, and Gateways folders.
Supported objects
The following objects are replicated:
The following information is replicated:
Supported LDAP commands
The following LDAP V.3 commands are supported:
• ADD
• DELETE
• MODIFY
• SEARCH.
MODIFY DN command
This command is supported only for users, contacts, and global mail lists (leaf nodes). It is used for:
• generic LDAP API (ASN.1 encoding of the "Modify DN" command), providing a standard, client-driven LDAP v3.0 MODIFY DN command
• LDIF file import and standard LDIF encoding of the MODIFY DN command
• scanning replicators (Active Directory and FCDS' Generic LDAP Replicator).
For scanning replicators, the detection of the MODIFY DN command is accomplished using a correlator attribute.
SEARCH command
The following restrictions apply to the SEARCH filter:
• only the following LDAP attributes are searchable:
• commonName
• givenName
• mail
• surname
• userid
• modifyTimeStamp
• all FCDS-supported object classes are searchable
• requested return attributes can be any FCDS-supported attributes
• the APPROXIMATE and EXTENSIBLE filters aren't supported.
Directory hierarchy
As you know, LDAP insists on a strict hierarchical structure for directory entries. In FirstClass, this hierarchy can be imposed by assigning organizational units (OUs) to user groups.
If you plan to use FCDS in LDAP mode, you must make sure that:
• you assign user groups that fit into your organization's hierarchy to OUs
Directory entries that only belong to groups not associated with OUs are placed at the root level of the FirstClass Directory tree.
• you assign OU levels to groups logically and consistently
FCDS builds the tree view from information received on a first-come basis. This means that a subsequent entry with inconsistent hierarchy information will be ignored.
• you list the user groups to which a user or public mail list belongs in the proper hierarchical order, with the highest-level group first.
When you set up privileges for your user groups, be aware of this hierarchical constraint. From the FirstClass server's perspective, the order in which you list groups determines the user's privileges. From the perspective of FCDS, the order determines the Directory tree view. These two purposes have the potential to be in conflict. Depending on the mode in which you run FCDS, you can avoid these conflicts.
Hierarchy example
This diagram shows the hierarchical structure of part of Husky Planes' Administration group:
 Linda Pringle works in the Library. The user groups to which she belongs are listed in this order on her User Information Form:
All Users
Regular Users
Corporate Information
Library
Corporate Information is associated with an OU that is at a higher level than the OU associated with Library. All Users and Regular Users are ignored by FCDS, so don't need to be associated with OUs.
The FirstClass Directory root DN is set to
ou=Administration,o=Husky Planes,c=CA
The resulting DN for Linda Pringle is
cn=Linda Pringle,ou=Library,ou=Corporate Information,ou=Administration,o=Husky Planes,c=CA
The LDAP tree view
When you connect to FCDS with an LDAP client, you'll see a tree like this:
 FCDS automatically creates these branches:
• Contacts
Lists all members of your personal address book.
• Subscription_Lists
Lists all member lists. Members' DNs are listed for each.
• Account_Lists
Lists all posixGroups. These are replicated as member lists. Members' user IDs are listed for each.
You'll only see Account_Lists if you set up FCDS to retrieve posixGroup information.
Who sees what
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||